Owning and maintaining a telecommunications or data network is a complex, challenging, and costly endeavor. Technology is constantly evolving at a rapid pace. As new features and device types are deployed, the tools used to manage networks must by continuously updated. This leads to escalating costs that must be carefully controlled in order to remain competitive. Another result of the rapid evolution of the network is that the tools must also be rapidly updated.
Accordingly, a burdensome task that plagues network owners is maintaining current and accurate records of the devices (elements) on the network. Exemplary networks include telecommunications networks and data networks. This problem is exacerbated as a network grows more complex. A mature network may span the globe. Keeping track of what devices are where, what equipment the devices contain, and what services are provisioned on them can be very difficult. This leads to underutilization of resources due to stranded assets that are not reflected in the network inventory, precipitating higher capitol and operational expenses.
One method employed to help mitigate this problem involves employing computer-automated network-discovery techniques. “Discovery” as used in the field of telecommunications and data networking is a term that refers to finding and identifying network components and their corresponding attributes. The information attained is used to audit and correct the network inventory, leading to a more efficient and cost-effective use of the network.
A discovery tool attempts to probe and gather data related to the devices on the network. But current discovery tools are not as efficiently deployed as they could be. For instance, one common approach has been to implement device-specific computer application code to communicate with a specific type of network element. A heterogeneous communications network is composed of elements from various vendors. Products from different vendors typically require different communications protocols. Moreover, communicating with various devices that are even made by the same manufacturer may require a very specific communications mechanism.
A prior-art component that has been used to communicate with network elements to retrieve device information is referred to as a NEM (Network Element Model), offered by the CoManage Corporation of Wexford, Pa. for use with their TrueSource™ software product (or developed by customers or system integrators who have acquired the TrueSource™ product). NEMs are used in connection with a discovery engine, which is a component of TrueSource™ that performs sweeps of a network to obtain configuration information. During these sweeps, a resolver framework maps device-specific NEMs to their respective network devices. Device-specific information is contained within such NEMs. Thus, a new NEM must be developed for every device type in the network that must be discovered.
NEM development can be divided into two major activities. First, a specific type of network device is analyzed. Based on business requirements for the given device type, an analyst must determine which components, attributes, and service elements need to be discovered. For those elements that support multiple communication protocols, the appropriate protocol must be selected. The queries or commands necessary to send to a device to perform discovery must be determined, along with the order in which those commands must be issued. The method of interpreting the response from the device, and how to translate and map the information returned into domain objects in the TrueSource™ data schema also must be specified by the analysis. The other major activity of prior-art NEM development is to implement the NEM code to perform session establishment, issue queries, parse the responses, perform translations and schema mappings, and to create and populate domain objects specified by the analysis. Session establishment and query generation can be aided by code wizards, but parsing, translations, and schema mappings require meticulous and specific code that must be hand-coded by a developer. Notable shortcomings of the prior-art include the need for multiple persons, manual-coding to produce a device-specific NEM, a compiling and deploying process, and a lengthy iterative review and correction process. Moreover, writing NEM code is typically tedious and prone to error.
Developing a separate NEM for every device type in the network is a time-intensive, resource-intensive, expensive, and inefficient method of providing components that perform discovery functions. Developing a NEM requires a device specialist who is familiar with the device to be communicated with, as well as a competent software developer skilled in the Java programming language. These roles may be performed by the same person, but finding someone having the necessary skills to perform both roles may be difficult. The device specialist determines what steps are required for performing discovery on a given device type, and the developer then writes code that performs those steps. The device specialist examines a specific device type and sets forth parameters for communicating with the devices. The device specialist must be intimately familiar with the given type of network device to be queried.
Network devices are often complex, and a fair amount of time can be expended learning how to communicate with a specific network device. The device specialist produces a document specifying the commands to issue to the given device, how to interpret the results received, and how to map and translate those results to the TrueSource™ data schema. The software developer then works within those parameters and, using the development framework/toolkit offered by CoManage for use with the TrueSource™ application, writes Java code that implements the functionality indicated by the device specialist's analysis.
After the coder develops the NEM, it must be tested. The test results must typically be examined by the device specialist, and, if errors are found, the analysis must be amended or corrected. The revised analysis must then be analyzed by the software developer who then updates the Java code to reflect the corrections to the analysis. This cycle usually continues for several iterations until no significant errors are detected during testing. Finally, the NEM is put into use. But again, it can only be used to interrogate a single, specific, device type. This process must be repeated for as many device types as there are on the network.
This prior-art solution is the approach used by Comanage, who offers the aforementioned TrueSource™ product and various NEMs for selected device types. This approach has put all device-specific knowledge in the NEMs (and resolvers), and has kept device-specific knowledge out of the rest of their system. This form of prior-art solution effectively confines device-specific code to the NEMs and is limited by at least two major factors. Because each NEM is developed for a specific type of network device, systems that contain many device types (which is common) require many NEMs to be developed and deployed. Encoding device-specific logic in the NEMs removes that design requirement the from rest of the prior-art system, but results in an inefficient development technique because so many NEMs have to be created. Another major factor is the inefficiencies arising from the length of the analyze/develop/test cycle required to develop a NEM. Because this cycle must usually be repeated many times, the amount of effort required for each cycle can have a dramatic negative effect on the cost of implementing the solution. An exemplary prior-art solution is represented in FIG. 1.
FIG. 1 includes a network-device specialist 110, a device-analysis report 112, a software developer 114, NEM source code 116, deployed code 118, and discovery results 120. At a step 122, specialist 110 analyzes a type of network device and produces an analysis report 112. The analysis report summarizes information specific to the given type of network device. The report is provided to developer 114 at a step 124. Developer 114 produces the NEM source code 116 at a step 126. The NEM code 116 is specific to the given type of network device. The code is compiled and deployed at a step 128 to produce deployed code 118, which will ultimately be used in the discovery system 100. Results 120 are returned for review to the analyst 110 at a step 132, where they are validated. If any errors or omissions are detected, the analysis report 112 is updated and again sent to the developer 114 for coding and testing. This cycle is repeated until the analysis is perfected and complete. The end result of these iterations will be a single NEM, a NEM specific to a single device type.
Dividing the analysis and implementation between two people makes maintaining a satisfactory level of productivity difficult. The device specialist 110 must wait for the developer 114 to finish implementing the code, compiling and deploying it, and running the tests to produce the results 120. The test results are then sent back to the analyst 110 for validation. The developer 114 must then wait for the analyst 110 to make changes to the analysis report 112 if changers are required. It is difficult to produce a complete and correct analysis on the first pass. It is also often helpful for the analyst to see a portion of the results before proceeding with further analysis. Because of these factors, repeating this cycle many times for each NEM developed is generally necessary.
The current state of the art could be improved by a discovery scheme that uses a network-element-discovery component that is device independent. There is a need for a discovery mechanism that is not constrained to individual device types but can be used across a broad range of network devices.